home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-madman-networkmib-02.txt < prev    next >
Text File  |  1993-07-08  |  15KB  |  442 lines
  1.  
  2.                             Internet Draft
  3.                     Network Services Monitoring MIB
  4.  
  5.                                Ned Freed
  6.                               Steve Kille
  7.  
  8.                           MADMAN Working Group
  9.                              June 26, 1993
  10.                        Expires: December 26, 1993
  11.  
  12. Status of this Memo
  13.  
  14. This document is an Internet Draft. Internet Drafts are working
  15. documents of the Internet Engineering Task Force (IETF), its Areas,
  16. and its Working Groups. Note that other groups may also distribute
  17. working documents as Internet Drafts.
  18.  
  19. Internet Drafts are draft documents valid for a maximum of six 
  20. months.    Internet Drafts may be updated, replaced, or obsoleted by
  21. other documents at any time.  It is not appropriate to use Internet
  22. Drafts as reference material or to cite them other than as a "working
  23. draft" or "work in progress."
  24.  
  25. Please check the I-D abstract listing contained in each Internet 
  26. Draft directory to learn the current status of this or any  other
  27. Internet Draft.
  28.  
  29. Abstract
  30.  
  31. This document defines the generic part of a MIB suitable for
  32. monitoring applications which provide some kind of network services.
  33. This MIB is intended to be extended to accomodate monitoring specific
  34. to a given type of service, for example, a Message Transfer Agent
  35. (MTA) service or a Directory Service Agent (DSA) service.
  36.  
  37. Rationale for having an Network Services Monitoring MIB
  38.  
  39. There is a substantial need to monitor applications which provide
  40. network services, particularly distributed components such as MTAs and
  41. DSAs, in order to measure load and to detect broken connectivity,
  42. system failure, congestion, and other types of problems. Specific
  43. requirements include:
  44.  
  45. (1) General monitoring of a large number of components (typical
  46.     for a large organization).
  47. (2) Integration with general network management.
  48.  
  49. SNMP is the clear choice for this function.  At present only simple
  50. read-only access is defined; this is sufficient to determine up/down
  51. status and provide an indication of a broad class of operational
  52. problems.   
  53.  
  54. Restriction of Scope
  55.  
  56. The framework provided here is very minimal; there is a lot more that
  57. could be done. For example:
  58.  
  59. (1) General network service application configuration.
  60. (2) Detailed examination and modification of individual entries in
  61.     service-specific request queues.
  62. (3) Probing to determine the status of a specific request (e.g. the
  63.     location of a mail message with a specific message-id).
  64. (4) Requesting that certain action be performed (e.g. forcing an
  65.     immediate connection and transfer of pending messages to some
  66.     specific system).
  67.  
  68. Whilst all these capabilities are both impressive and useful, to be
  69. effective, security is an absolute requirement. These capabilities
  70. also mandate a much more complex design with many characteristics
  71. likely to be fairly implementation-specific. As a result such
  72. facilities are likely to be both contentious and difficult to
  73. implement. 
  74.  
  75. This document religiously keeps things simple and focuses on the basic
  76. monitoring aspect of managing applications providing network services. 
  77. The goal here is to provide a framework which is simple, useful, and
  78. widely implementable.
  79.  
  80. Relationship to Directory Services
  81.  
  82. Use of and management of directory services already is tied up with
  83. network service application management.  There are clearly many things
  84. which could be dealt with by directory services and protocols.  We
  85. take the line here that static configuration information is both
  86. provided by and dealt with by directory services and protocols. The
  87. emphasis here is on transient application status.
  88.  
  89. By placing static information in the directory, the richness and
  90. linkage of the directory information framework does not need to be
  91. repeated in the MIB.  Static information is information which has a
  92. mean time to change of the order of days or longer.
  93.  
  94. When network service applications that employ directory services
  95. are monitored, it is recommend that a linkage be established, so
  96. that:
  97.  
  98. (1) The managed object contains its own directory name.  This
  99.     allows all directory information to be obtained by reference.
  100.     This will let a SNMP monitor capable of performing directory
  101.     queries present this information to the manager in an
  102.     appropriate format.  It is intended that this will be the
  103.     normal case. 
  104. (2) The directory will reference the location of the SNMP agent,
  105.     so that an SNMP capable directory query agent could probe
  106.     dynamic characteristics of the object.  
  107. (3) This approach could be extended further, so that the SNMP
  108.     attributes are modelled as directory attributes.  This would
  109.     dramatically simplify the design of directory service agents
  110.     that use SNMP to obtain the information they need.
  111.  
  112. Application Objects
  113.  
  114. This MIB starts with a set of general purpose attributes which would
  115. be appropriate for a range of applications that provide network
  116. services.  Both OSI and non-OSI services can be accomodated.
  117. Additional tables defined in extensions to this MIB provide attributes
  118. specific to specific network services.
  119.  
  120. A table is defined which will have one row for each network service
  121. application running on the system.  The only static information held
  122. on the application is its distinguished name.  All other static
  123. information should be obtained from various directory services.  The
  124. applName is an external key, which allows an SNMP MIB entry to
  125. be cleanly related to the X.500 Directory.  In SNMP terms, the
  126. applications are grouped in a table called applTable, which is indexed
  127. by an integer key applIndex.
  128.  
  129. The type of the application will be determined by one or both of:
  130.  
  131. (1) Additional MIB variables specific to the applications.
  132. (2) An association to the application of a specific protocol.
  133.  
  134. APPLICATION-MIB DEFINITIONS ::= BEGIN
  135.  
  136. IMPORTS
  137.   OBJECT-TYPE FROM RFC1212
  138.   experimental, Counter, Gauge, TimeTicks FROM RFC1151-SMI
  139.   DisplayString FROM RFC1213-MIB;
  140.  
  141. application OBJECT IDENTIFIER ::= {experimental 46}
  142.  
  143. applTable OBJECT-TYPE
  144.     SYNTAX SEQUENCE OF ApplEntry
  145.     ACCESS not-accessible
  146.     STATUS mandatory
  147.     DESCRIPTION
  148.         "The table holding objects which apply to all different
  149.          kinds of applications providing network services."
  150.     ::= {application 1}
  151.  
  152. applEntry OBJECT-TYPE
  153.     SYNTAX ApplEntry
  154.     ACCESS not-accessible
  155.     STATUS mandatory
  156.     DESCRIPTION
  157.       "An entry associated with a network service application."
  158.     INDEX {applIndex}
  159.     ::= {applTable 1}
  160.  
  161. ApplEntry ::= SEQUENCE {
  162.     applIndex
  163.         INTEGER,
  164.     applName
  165.         DisplayString,
  166.     applVersion
  167.         DisplayString,
  168.     applOperStatus
  169.         INTEGER,
  170.     applLastChange
  171.         TimeTicks,
  172.     applInboundAssociations
  173.         Gauge,
  174.     applOutboundAssociations
  175.         Gauge,
  176.     applAccumulatedInboundAssociations
  177.         Counter,
  178.     applAccumulatedOutboundAssociations
  179.         Counter,
  180.     applLastInboundActivity
  181.         TimeTicks,
  182.     applLastOutboundActivity
  183.         TimeTicks,
  184.     applRejectedInboundAssociations
  185.         Counter,
  186.     applFailedOutboundAssociations
  187.         Counter
  188. }
  189.  
  190. applIndex OBJECT-TYPE
  191.     SYNTAX INTEGER (1..2147483647)
  192.     ACCESS read-only
  193.     STATUS mandatory
  194.     DESCRIPTION
  195.       "An index to uniquely identify the network service
  196.        application."
  197.     ::= {applEntry 1}
  198.  
  199. applName OBJECT-TYPE
  200.     SYNTAX DisplayString
  201.     ACCESS read-only
  202.     STATUS mandatory
  203.     DESCRIPTION
  204.       "The name the network service application chooses to be
  205.        known by."
  206.     ::= {applEntry 2}
  207.  
  208. applVersion OBJECT-TYPE
  209.     SYNTAX DisplayString
  210.     ACCESS read-only
  211.     STATUS mandatory
  212.     DESCRIPTION
  213.       "The version of network service application software."
  214.     ::= {applEntry 3}
  215.  
  216. applOperStatus OBJECT-TYPE
  217.     SYNTAX INTEGER {
  218.       up(1),
  219.       down(2),
  220.       halted(3),
  221.       congested(4),
  222.       restarting(5)
  223.     }
  224.     ACCESS read-only
  225.     STATUS mandatory
  226.     DESCRIPTION 
  227.       "Indicates the operational status of the network service
  228.        application. 'down' indicates that the network service is
  229.        not available. 'running' indicates that the network service
  230.        is operational and available.  'halted' indicates that the
  231.        service is operational but not available.  'congested'
  232.        indicates that the service is operational but no additional
  233.        inbound associations can be accomodated.  'restarting'
  234.        indicates that the service is currently unavailable but is
  235.        in the process of restarting and will be available soon."
  236.     ::= {applEntry 4}
  237.  
  238. applLastChange OBJECT-TYPE
  239.     SYNTAX TimeTicks
  240.     ACCESS read-only
  241.     STATUS mandatory
  242.     DESCRIPTION
  243.       "The value of sysUpTime at the time the network service
  244.        application entered its current operational state.  If
  245.        the current state was entered prior to the last
  246.        initialization of the local network management subsystem,
  247.        then this object contains a zero value."
  248.     ::= {applEntry 5}
  249.  
  250. applInboundAssociations OBJECT-TYPE
  251.     SYNTAX Gauge
  252.     ACCESS read-only
  253.     STATUS mandatory
  254.     DESCRIPTION
  255.       "The number of current associations to the network service
  256.        application, where it is the responder.  For dynamic single
  257.        threaded processes, this will be the number of application
  258.        instances."
  259.     ::= {applEntry 6}
  260.  
  261. applOutboundAssociations OBJECT-TYPE
  262.     SYNTAX Gauge
  263.     ACCESS read-only
  264.     STATUS mandatory
  265.     DESCRIPTION
  266.       "The number of current associations to the network service
  267.        application, where it is the initiator.  For dynamic single
  268.        threaded processes, this will be the number of application
  269.        instances."
  270.     ::= {applEntry 7}
  271.  
  272. applAccumulatedInboundAssociations OBJECT-TYPE
  273.     SYNTAX Counter
  274.     ACCESS read-only
  275.     STATUS mandatory
  276.     DESCRIPTION
  277.       "The total number of associations to the application entity
  278.        since application initialization, where it was the responder.
  279.        For  dynamic single threaded processes, this will be the
  280.        number of application instances."
  281.     ::= {applEntry 8}
  282.  
  283. applAccumulatedOutboundAssociations OBJECT-TYPE
  284.     SYNTAX Counter
  285.     ACCESS read-only
  286.     STATUS mandatory
  287.     DESCRIPTION
  288.       "The total number of associations to the application entity
  289.        since application initialization, where it was the initiator.
  290.        For dynamic single threaded processes, this will be the
  291.        number of application instances."
  292.     ::= {applEntry 9}
  293.  
  294. applLastInboundActivity OBJECT-TYPE
  295.     SYNTAX TimeTicks
  296.     ACCESS read-only
  297.     STATUS mandatory
  298.     DESCRIPTION
  299.       "The time since this application has had an inbound
  300.        association."
  301.     ::= {applEntry 10}
  302.      
  303. applLastOutboundActivity OBJECT-TYPE
  304.     SYNTAX TimeTicks
  305.     ACCESS read-only
  306.     STATUS mandatory
  307.     DESCRIPTION
  308.       "The time since this application has had an outbound
  309.        association."
  310.     ::= {applEntry 11}
  311.  
  312. applRejectedInboundAssociations OBJECT-TYPE
  313.     SYNTAX Counter
  314.     ACCESS read-only
  315.     STATUS mandatory
  316.     DESCRIPTION
  317.       "The total number of inbound associations the application
  318.        entity has rejected, since application initialization."
  319.     ::= {applEntry 12}
  320.  
  321. applFailedOutboundAssociations OBJECT-TYPE
  322.     SYNTAX Counter
  323.     ACCESS read-only
  324.     STATUS mandatory
  325.     DESCRIPTION
  326.       "The total number associations where the application entity
  327.        is initiator and association establishment has failed,
  328.        since application initialization."
  329.     ::= {applEntry 13}
  330.  
  331. -- The basic applTable contains a list of the application entities.
  332. -- A second table is maintained, which holds the list of
  333. -- associations.  This is treated as a separate group to the basic
  334. -- application table.  Where simplified appplication monitoring is
  335. -- needed, the assocTable group may be omitted. This table is
  336. -- indexed by applIndex and assocIndex, with the application index
  337. -- coming first.   
  338.  
  339. assocTable OBJECT-TYPE
  340.     SYNTAX SEQUENCE OF AssocEntry
  341.     ACCESS not-accessible
  342.     STATUS mandatory
  343.     DESCRIPTION
  344.         "The table holding a set of all active application
  345.          associations."
  346.     ::= {application 2}
  347.  
  348. assocEntry OBJECT-TYPE
  349.     SYNTAX AssocEntry
  350.     ACCESS not-accessible
  351.     STATUS mandatory
  352.     DESCRIPTION
  353.       "An entry associated with an association for a network
  354.        service application."
  355.     INDEX {applIndex, assocIndex}
  356.     ::= {assocTable 1}
  357.  
  358. AssocEntry ::= SEQUENCE {
  359.     assocIndex
  360.         INTEGER,
  361.     assocRemoteApplication
  362.         DisplayString,
  363.     assocApplicationProtocol
  364.         OBJECT IDENTIFIER,
  365.     assocApplicationType
  366.         INTEGER,
  367.     assocDuration
  368.         TimeTicks
  369. }
  370.  
  371. assocIndex OBJECT-TYPE
  372.     SYNTAX INTEGER (1..2147483647)
  373.     ACCESS read-only
  374.     STATUS mandatory
  375.     DESCRIPTION
  376.       "An index to uniquely identify each association for a network
  377.        service application."
  378.     ::= {assocEntry 1}
  379.  
  380. assocRemoteApplication OBJECT-TYPE
  381.     SYNTAX DisplayString
  382.     ACCESS read-only
  383.     STATUS mandatory
  384.     DESCRIPTION
  385.       "The name of the system running remote network service
  386.        application.  For an IP-based application this should be
  387.        either a domain name or IP address.  For an OSI application
  388.        it should be the string encoded distinguished name of the
  389.        managed object using the format defined in RFC-?.  For
  390.        X.400(84) MTAs which do not have a Distinguished Name, the
  391.        RFC-1327 syntax 'mta in globalid' should be used."
  392.     ::= {assocEntry 2}
  393.  
  394. assocApplicationProtocol OBJECT-TYPE
  395.     SYNTAX OBJECT IDENTIFIER
  396.     ACCESS read-only
  397.     STATUS mandatory
  398.     DESCRIPTION
  399.       "An identification of the protocol being used for the
  400.        application.  For an OSI Application, this will be the
  401.        Application Context.  For Internet applications, the IANA
  402.        maintains a registry of the OIDs which correspond
  403.        to well-known applications.  If the application protocol is
  404.        not listed in the registry, the value {applProtoID port} is
  405.        used where 'port' corresponds to primary port being used by
  406.        the application."
  407.     ::= {assocEntry 3}
  408.  
  409. assocApplicationType OBJECT-TYPE
  410.     SYNTAX INTEGER {
  411.         ua-initiator(1),
  412.         ua-responder(2),
  413.         peer-initiator(3),
  414.         peer-responder(4) }
  415.     ACCESS read-only
  416.     STATUS mandatory
  417.     DESCRIPTION 
  418.       "Shows whether the remote application is a User Agent, or a
  419.        peer server, and whether the remote end is initiator or
  420.        responder."
  421.     ::= {assocEntry 4}
  422.  
  423. assocDuration OBJECT-TYPE
  424.     SYNTAX TimeTicks
  425.     ACCESS read-only
  426.     STATUS mandatory
  427.     DESCRIPTION
  428.       "The time that the association has been open."
  429.     ::= {assocEntry 5}
  430.  
  431. applProtoID OBJECT IDENTIFIER ::= {application 3}
  432.  
  433. -- Values of the form { applProtoID port } are used for
  434. -- protocols that don't have assigned OIDs. 'port'
  435. -- corresponds to primary port being used by the
  436. -- application.
  437.  
  438. END
  439.  
  440. Expires: December 26, 1993
  441.  
  442.